As digital data processing systems become larger and more complex, comprising ever more components, the likelihood of failures increases, as does the difficulty of finding the component which has failed or which is otherwise faulty. Designers are including features in components to facilitate their being tested to determine whether they operate as designed.
However, traditional approaches to troubleshooting have drawbacks that render them less effective as systems become more complex. Given a failure, the traditional approaches enable a set of input values to be determined for which the output of the failed component differs from that expected of a good component. That is, the traditional approaches provide a theory of "test generation," rather than actually diagnosing failed components. They provide little assistance in identifying what failure to consider or, more importantly, what component to suspect to have failed.
Another drawback to current methods of troubleshooting is that they are generally "ad hoc" to a single circuit or system, and it is difficult to modify or adapt them to handle evolving or changing configurations, which is typical of digital data processing systems. This is particularly true of various expert systems employing rules, where the rules usually limited to specific configurations. Typically, the rules result from extensive and time-consuming discussions with experts, and when the configuration changes new rules have to be provided, often requiring repeating the discussions. Further, if the expert system does not have a rule for a particular circumstance, it is unable to provide assistance, and, when that occurs, service personnel often must interact with the design engineers to locate the failed component. Thus, coping with configurational and other system changes often requires extensive commitments of time by the design engineers, as well as service personnel.